Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Obtain auth tokens via the new azidentity/MSAL method #1926

Closed
wants to merge 9 commits into from

Conversation

thomas11
Copy link
Contributor

@thomas11 thomas11 commented Aug 19, 2022

This PR replaces the default implementation of getOAuthToken with one that uses the new azidentity package, part of azure-sdk-for-go, to obtain an Azure auth token. This is also known as MSAL, whereas the previous, deprecated method is ADAL.

Multitenant OAuth is not implemented yet in azidentity, that's the only feature gap I'm aware of. For that, we'll continue to fall back on ADAL.

@github-actions
Copy link

Does the PR have any schema changes?

Looking good! No breaking changes found.
No new resources/functions.
Looking good! No API changes found.

examples/go-auth/main.go Outdated Show resolved Hide resolved
@viveklak
Copy link
Contributor

The main reason this PR is a draft that of the multiple authentication options I have only tested Azure CLI so far.

This looks great! Pardon my ignorance but what auth options are currently possible with the old ADAL? I think if we get parity there and can get test coverage for the scenarios, we should feel fairly confident about pushing this through.

provider/pkg/provider/provider.go Outdated Show resolved Hide resolved
@@ -233,7 +250,7 @@ func (k *azureNativeProvider) Invoke(ctx context.Context, req *rpc.InvokeRequest
if endpointArg := args["endpoint"]; endpointArg.HasValue() && endpointArg.IsString() {
endpoint = endpointArg.StringValue()
}
token, err := k.getOAuthToken(ctx, auth, endpoint)
token, err := k.getOAuthTokenNew(ctx, auth, endpoint)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we have some trepidation on support, we can add the new API behind an experimental provider option - we do this often in other providers, e.g. kubernetes: https://github.com/pulumi/pulumi-kubernetes/blob/master/provider/pkg/provider/provider.go#L436

Copy link
Contributor Author

@thomas11 thomas11 Aug 19, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's the kind of pointer I was hoping for :) Is there any precedent for making instead the previous version opt-in? In this case, customers are already asking for the new version so we don't want to delay too much.

Note that - unless I misunderstand something? - there is no API change here, the change is internal.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's the kind of pointer I was hoping for :) Is there any precedent for making instead the previous version opt-in? In this case, customers are already asking for the new version so we don't want to delay too much.

Yes we have done something similar elsewhere before, i.e. make reverting to old default opt-in.

Note that - unless I misunderstand something? - here is no API change here, the change is internal.

Yup we are on the same page here. I honestly think we can probably be somewhat aggressive here and just go with it. If users are having issues, they can pin to an older version of the provider as a fallback.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the new way of working is backward compatible then let's just push forward

If it's not, we may need to allow people to opt-in

@github-actions
Copy link

Does the PR have any schema changes?

Looking good! No breaking changes found.
No new resources/functions.
Looking good! No API changes found.

@thomas11
Copy link
Contributor Author

The main reason this PR is a draft that of the multiple authentication options I have only tested Azure CLI so far.

This looks great! Pardon my ignorance but what auth options are currently possible with the old ADAL? I think if we get parity there and can get test coverage for the scenarios, we should feel fairly confident about pushing this through.

ADAL with the hashicorp package tries these auth options:

  1. servicePrincipalClientCertificateAuth,
  2. servicePrincipalClientSecretMultiTenantAuth,
  3. servicePrincipalClientSecretAuth,
  4. managedServiceIdentityAuth,
  5. azureCliTokenAuth

I have replicated this order in my PR, except (2) is not supported yet by azidentity. And I've tested only (5) so far.

Copy link
Member

@danielrbradley danielrbradley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks great - really nice that we can re-use all the same configuration.

Btw, another alternative to using q is to attach to the provider and step through - I've just written the instructions for debugging providers in our team docs.

@thomas11
Copy link
Contributor Author

The main reason this PR is a draft that of the multiple authentication options I have only tested Azure CLI so far.

I have now tested service principal with cert and service principal with client secret. MSI (managed identity) is only available when running in certain Azure environments, but I have verified that setting ARM_USE_MSI attempts to use it as expected.

@thomas11 thomas11 force-pushed the tkappler/msal-azidentity-auth branch from 71cfff0 to f4f35a5 Compare August 23, 2022 03:51
@github-actions
Copy link

Does the PR have any schema changes?

Looking good! No breaking changes found.
No new resources/functions.
Looking good! No API changes found.

@thomas11 thomas11 force-pushed the tkappler/msal-azidentity-auth branch from f4f35a5 to e33a3eb Compare August 23, 2022 20:18
@github-actions
Copy link

Does the PR have any schema changes?

Looking good! No breaking changes found.
No new resources/functions.
Looking good! No API changes found.

@thomas11 thomas11 marked this pull request as ready for review August 23, 2022 23:52
@github-actions
Copy link

Does the PR have any schema changes?

Looking good! No breaking changes found.
No new resources/functions.
Looking good! No API changes found.

@thomas11 thomas11 force-pushed the tkappler/msal-azidentity-auth branch from 2c66daf to 324583a Compare August 24, 2022 16:27
@github-actions
Copy link

Does the PR have any schema changes?

Looking good! No breaking changes found.
No new resources/functions.
Looking good! No API changes found.

@thomas11 thomas11 force-pushed the tkappler/msal-azidentity-auth branch from 324583a to 22d2d3d Compare August 25, 2022 18:00
@github-actions
Copy link

Does the PR have any schema changes?

Looking good! No breaking changes found.
No new resources/functions.
Looking good! No API changes found.

@thomas11 thomas11 force-pushed the tkappler/msal-azidentity-auth branch from 22d2d3d to 316d69c Compare August 26, 2022 21:15
@github-actions
Copy link

Does the PR have any schema changes?

Looking good! No breaking changes found.
No new resources/functions.
Looking good! No API changes found.

@thomas11 thomas11 marked this pull request as draft October 28, 2022 20:35
@thomas11 thomas11 added the resolution/duplicate This issue is a duplicate of another issue label Mar 31, 2023
@thomas11
Copy link
Contributor Author

Implemented by #2320

@thomas11 thomas11 closed this Mar 31, 2023
@thomas11 thomas11 deleted the tkappler/msal-azidentity-auth branch February 13, 2024 06:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
resolution/duplicate This issue is a duplicate of another issue
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants